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Two New Smalltalks 


S malltalk is a very loose term. While there are some 
clear, defining characteristics, there are also many 
variations as well. This is important because software 
development is a large field, with different solutions 
appropriate to different problems. This article will discuss 
some of these possible variations, with reference to two 
promising new implementations. 

The first of these new implementations is Object 
Connect’s "Smalltalk MT,” a high-performance imple¬ 
mentation for Windows NT 4.0, with full compilation and 
true multithreading. The second is Intuitive Systems’ 
"Dolphin Smalltalk,” which boasts a low cost and a very 
low memory footprint. 

Neither one has been officially released yet, but free 
prerelease copies are available for download from their 
Web sites (see contact information at the end). Even if 
you’ve missed thefree periods, both companies are aiming 
at product prices in the low hundreds (of U.S.) dollars. 

Note that I looked at prerelease versions, and that I’ve 
only played with them,so all I can do is relay first impres¬ 
sions and generalities about their implementation choic¬ 
es. I hope you'll see a full review in these pages once they 
are officially released. 

COMPILATION 

Most current Smalltalks use dynamic compilation, now 
commonly referred to asJust-ln-Time (JIT) compilation. 
This is an example of a process I call "cross-domain buzz¬ 
word hybridization." In this process, a recognized buzz¬ 
word from one domain crosses over to another, where it 
attaches to a concept almost, but not quite, entirely 
unlike the original. If you don't like it, think of it as pay¬ 
back for the term "object-oriented." 

In dynamic compilation, the methods are stored in 
bytecode form. At runtime, some (or all) of these byte¬ 
codes are translated into machine code. This can provide 
most of the speed of machine code with a much smaller 
executable size, comparable to that of bytecodes. 

Although this is a good approach, it's not a perfect solu¬ 
tion for every circumstance. It takes more space than byte¬ 
codes (you now have to store both compiled forms) and 
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still won't run as quickly as compiled code (you have to 
spend CPU cycles to translate, and you can’t afford to think 
too hard about optimization). Finally, it requires a VM to 
do the translating, which makes it more difficult to create 
standalone executables, DLLs, and cal I back functions. 

Smalltalk MT isfullycompiled, and has "an optimizing 
compiler that generates fast, compact code." Full compi¬ 
lation should give significantly better performance than 
exi sti ng i mpl ementati ons, and the absence of a VM all ows 
simple programs to be very small indeed. MT claims to be 
able to make DLLs (which, to my knowledge, no existing 
Smalltalkcan do), and to fit atrivial windows application 
into a 100K executable (their runtime-sup port DLL adds 
only52K). 

Dolphin Smalltalk is bytecode interpreted. I would 
expect this to offer si gnificantly siower performance than 
current implementations, but with much lower space 
consumption, even for significant-sized applications.The 
company states that it "will be producing an optional JIT 
in future.” When space is more important than speed, this 
is a very reasonable option, and this is often true in 
applets. The firm also says it will shortly have its VM 
encapsulated as an ActiveX downloadable. 

SIZE 

Both companies advertise their ability to make very smal I 
executables. Traditionally this has been a weak area for 
Smalltalk. In many of the application areas for which 
Smal Ital k is used, one can argue that size doesn’t matter as 
longasitdoesthejob. But with the growing importance of 
small applets over monolithic applications, size is becom¬ 
ing more significant. 

Dolphin’s approach to minimizing size uses bytecod¬ 
ing and a very small interpreter (I counted 155K including 
all the DLLs) with a relatively standard (but small) image. 
Their prerelease packaging support wasn’t very sophisti¬ 
cated, but when a development image starts at only 1.4 
MB a good stripper is more of a luxury. 

Smalltalk MT can provide extremely small sizes for 
simple programs, but for larger programs the space cost 
of full compilation becomes significant. The firm tries to 
combat this through modular class libraries and a mini¬ 
malist framework. 

The typical Smalltalk programmer doesn’t think too 
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much before using something that’s in the development 
image. This is nice for development but bad for packag¬ 
ing. Everything depends on everything else, and all you 
can do is remove the compiler and development tools. 
MT claims to have kept the base classes small and mod¬ 
ular, so if you don't use a particular class or subsystem it 
can easily be removed. They also claim to have a sophis¬ 
ticated packager, though I'm skeptical. Packaging is a dif¬ 
ficult problem. I figure their base image, including the 
compiler and development DLLs, is 1.3 M B. "Imagegen- 
eration is largely automatic. An Image Builder com¬ 
putes the set of referenced classes and methods, start¬ 
ing with the image-entry point." 

MT has also minimized thesizeof the runtime by stick- 
i ng very close to the OS functional ity. 

'All GUI and operating system-related classes present 
a Win32-like protocol. This ensures that applications 
run with minimum overhead on the Windows family of 
operating systems, and leverage 
on existing know-how." S malltalkisa 


FRAMEWORKS mincurac* 

A Win32-like protocol for window- d&fiflingChdH 
ingisdefinitelyatwo-edged feature. , 

It makes Windows programmers dlcdlbU illdil 

who have programmed in other 1 / 1 / 

languages feel right at home, and it 
minimizes the amount of code you need to map a 
Smalltalk framework onto the operating system. I think 
there’s no question that this reduces the amount of code i n 
the i mage. 

On the other hand, frameworks that are written with 
C or C++ in mind look really ugly compared to those 
designed for Smalltalk. Look at Visual Smalltalkvs. IBM. 
Visual Smalltalk has tight integration with Windows, to 
the point where you can implement your own wm:what- 
ever: messages, but provides a very clean, simple, 
Smalltalk-like framework above that. IBM has its 
X/Motif layer, which translates into cal Is to the real OS. It 
works very well, and it's extremely portable, but it's way 
too close to C programming for my taste. IBM’s saving 
grace is that withVisualAgeorWindowBuilderyou rarely 
have to descend to that level. Smalltalk MT doesn’t 


in the development THREADS 

but bad for packag- One of the most innovative features of Smalltalk MT is its 

ng else, and all you full support for operating system threads ("true" multi¬ 
development tools. threading). Making a decent compiler isn't that hard, but 

;ses small and mod- there are many issues involved in making Smalltalk use 

:lass or subsystem it OS threads. The only other implementation I know of is 

m to have a sophis- OTI’s embedded systems implementation, and it only 

il. Packaging is a dif- supportsthreadsfor real-time operating systems, 

nage, including the I believe OS threads are often given too much impor- 
L.3MB."lmagegen- tance. For 90% of applications, the standard Smalltalk 

nage Builder com- process model will suffice, along with the ability to make 

and methods, start- system calls without blocking. The critical issue is that 
when one Smalltalk process waits on a system service, the 
:he runtime by stick- entire Smalltalk system should not wait. Given thiscapa- 
bility, which most implementations provide, it's not diffi- 
ated classes present cult to render demanding applications like Web or termi- 

s that applications nal servers, and you don't have to deal with the addition- 
i Windows family of al complexities of OS threads. With the Smalltalk model 

you can even have thread-manipu- 
Smalltalkisa very loose term, lating code that’s portable between 

Whilp thprparp q nmp rlpar operati ng systems ’ 

wniieLneredresumeuear, That - S a ver7 good solution when it 

defining characteristics, there works, but there are times when you 

prp also manv variations as really need 0Sthreads - Oneexampie is 
are at so many van an ons as sym metric multiprocessing (smp). 

1 / 1 /qI /. Operati ng systems that support multi - 

pleCPUsin one machine can map OS 
du need to map a threads to different processors, but not Smalltalk processes, 
ting system. I think Presently,thisaffectsonlyvery high-end machines, butitwill 
ie amount of code in become more and more important in the future. 

Given that there are lots of implementations out there 
hat are written with with the standard threadingmodel,thechoiceof usingOS 
compared to those threadsin SmalltalkMT isa very welcomeoneindeed. 


PLATFORMS AND PRICE 

By now I 11 bet you are impatient to get your own copy of 
either or both of these implementations for your favorite 
platform. Unless you’re a M icrosoft fan you’re out of luck. 
Both of these implementations have opted away from 
portabi lity i n favor of close i ntegration with Wi n32.1 n fact, 
the fi rst versi on of Smal ItalkMTrunsonlyonWi ndows NT 
4.0 due to problems with Wi n95's threads, but they expect 
to have a Wi ndows 95 version soon . 


appear to have a GUI builder. On the other hand, I'm 
sure there are lots of people using C/C++for whom a 
Win32-like framework in Smalltalk (especially a 
Smalltalk that can produce fast, compact executables) 
would be a big step up. 

Dolphin Smalltalk, in contrast, uses MVC. This is the 
oldest and best known of the Smalltalk frameworks, and 
has been passed down from PARC into Visual Works. 
Dolphin has adapted it to a native-widget, event-driven 
form, but it still has Views, Controllers, and even 
ValueModels. They’ve also included a mediator class 
(called Tool) analogous to the Application Model of 
VisualWorks. I haven’t tried building a window with either 
dialect but I’d expect to feel more comfortable with 
Dolphin. 


Dolphin Smalltalk has gotten more attention on the 
Net, because it can also run on older versions of NT and 
Windows 95. Don't expect them to expand their list of 
platforms too much. In response to a number of calls for 
an OS/2 version, Andy Bower of Dolphin’s support group 
(Dolphin.support@intuitive.co.uk) wrote: 

'The initial design aims for Dolphin were firmly 
di rected to produci ng a geat Wi n32 development system 
and this assumption is built into the product at a low 
le\«L... we'd be reluctant to compromise this for compat¬ 
ibility with other environments." 

As for pricing, both are very low compared to the current 
standards Neither has fixed afirm price yet, but from what 
I’ve heard MT is approximately U.S. $300, and Dolphin at 
under U .S. $200. continued on page26 
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MANAGING OBJECTS _ 

never really "get 00." After a reasonable time period (per¬ 
haps as long as nine months), the people who still haven’t 
gotten it need to be given alternatives. Neither the mentor 
nor the developer is to blame. Not all people are able to 
think abstractly, and they need to be given the chance to 
contribute to the organization in ajob for which they are 
suited. 

CONCLUSION 

"Smalltalk guru" is not the equivalent to Smalltalk men¬ 
tor. Not all team members will accept mentoring, and 
not all team members will get 00. Do the best you can as 
a mentor and as a developer, and try to keep egos out of 
the equation. If personality clashes are a problem, 
maybe the mentor has to go. This is a tough call that the 
manager will have to make. Good luck and happy men¬ 
toring! a 
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continued from page23 

OVERALL 

Overall I'm quite impressed with both of these implementa¬ 
tions. As prerelease products, they’reobviously immature in 
some areas. For example, I had difficulty with the debugger 
in bothofthem.TheGUI builderin Dolphindidn'tworkyet, 
and MT doesn’t appear to have one. On the other hand, in a 
lot of areas, they’re surprisingly mature. They already have 
advanced features like finalization and exception handling 
in place. Inevitably, it will be a while before they’re fully 
loaded with those features that have nothing to do with a 
language, and everything to do with a successful project: 
industrial-strength source code control, native database 
connections, extra widgetry, report writers, business graph¬ 
ics, and so forth. Nevertheless, they show enormous poten¬ 
tial, and are well worth your whileto investigate. 

Of the two, I expect MT to be the first choice for those 
looking for cool new features, and for those doing things 
that are traditionally difficult in Smalltalk (e.g. server- 
based Smalltalk, very tiny apps). Restriction to the newest 
version of NT will lessen their impact in the short term. 
Dolphin Smalltalk, with a very low price, Win95 support, 
MVC, and ActiveX applet support, has real potential to 
become the Smal Ital k for the masses. 

Both are filling niches that are under-represented by 
current implementations, and I hope they will enjoy great 
success, a 
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